Коллеги рассказали про интересный случай: создали RDM-диск для двух виртуальных машин MSCS-кластера "across boxes", подцепили его к виртуальным машинам на двух хостах ESXi, а производительность на нем упала до 10 МБ/сек, хотя этот диск находится на быстром FC-хранилище EMC VNX и скорость должна измеряться сотнями МБ/сек. При этом в качестве хост-платформы используется VMware vSphere 5.1.

Ответ оказался простым - для хранилищ EMC VNX хост ESXi выставляет политику путей по умолчанию Round Robin (балансировка по двум путям). При использовании кластера MSCS на кворумном диске вызываются SCSI-3 резервации. SCSI-3 резервация (registration) посланная по одному пути позволяет производить дальнейшие резервации или SCSI-команды только по этому пути.

А при использовании политики Round Robin, когда плагин PSP_RR переключает на другой путь, кластер MSCS получает ошибку и пробует сделать SCSI-3 резервацию повторно или выполнить другие команды.

Поэтому вместо политики Round Robin для конкретного хранилища и для данного RDM-диска надо использовать следующие политики путей (плагины PSP_MRU или PSP_FIXED), в зависимости от типа хранища. Они приведены в KB 1010041 и в таблице ниже:

Для того, чтобы выставить политику путей, нужно в разеле Storage в vSphere Client выбрать нужный HBA-адаптер и устройство, для которого создан RDM-диск, и из его контекстного меню выбрать пункт Manage Paths (это также можно сделать в свойствах виртуальной машины для диска):

После выставления корректной политики путей скорость для кворумного диска MSCS вырастет в разы. Кстати, если вы используете VMware vSphere 5.5 и выше, то такого поведения там уже нет, и все работает корректно.

О новых возможностях VMware vSphere 5.5 по поддержке кластеров MSCS мы уже писали вот тут.

Иногда при установке cервера VMware vCenter 5.1 или толстого клиента VMware vSphere Client 5.1 (пока мы еще ждем vSphere 5.5) на Windows Server 2012 мы получаем вот такое сообщение:

Internal error 28173

Это все потому, что у вас не установлен Microsoft .NET Framework 3.5, который требуется для работы компонентов VMware vCenter.

Решается проблема просто. Надо запустить Server Manager, запустить мастер "Add roles and features wizard" и установить .NET Framework 3.5:

После этого установка vCenter или vSphere Client пройдет успешно.

Продолжаем знакомить вас с багами VMware vSphere 5.1 - ведущей платформы виртуализации. На этот раз мы расскажем о баге VMware vSphere Client, для чего откроем вкладку редактирования пользователя и посмотрим на его свойства:

Такую картину мы увидим в том числе и тогда, когда пользователь VMware ESXi был создан автоматически, например, при использовании функций AutoDeploy и Host Profiles. Не очень понятно, почему это пользователю при создании по дефолту гарантируются права на доступ к консоли ESXi, а вот в списке групп, где он состоит, наблюдается пустота.

Все на самом деле просто: в vSphere 5.1 поменялся подход к безопасности, а вот сделать обновление vSphere Client забыли, так как сейчас идет переход на vSphere Web Client, и никому нет дела до толстого клиента. Соответственно, аспекты этого бага таковы:

• Галка "Grant shell access to this user" ни на что не влияет. Важно только, назначена ли роль Administrator пользователю (что позволит ему войти в консоль сервера).
• Поле Group пустое, так как ESXi больше не использует информацию из /etc/groups, а использует свою модель пользователей и групп:

• Поэтому вновь создаваемый пользователь с галкой "Grant shell access to this user" не сможет соединиться по SSH и зайти в консоль, то есть это баг UI:

В самом конце прошлой недели компания VMware выпустила обновление своей серверной платформы виртуализации - VMware vSphere 5.1 Update 1. Напомним, что версия vSphere 5.1 вышла еще летом прошлого года, поэтому апдейт продукта назрел уже давно.

Из официального списка новых возможностей VMware vSphere 5.1 Update 1:

• Поддержка новых гостевых ОС, приведенных в списке совместимости VMware.
• Исправления ошибок, приведенные здесь.

Надо сказать, что после vSphere 5.1 Update 1, следующие гостевые ОС НЕ будут поддерживаться со стороны VMware (этот релиз пока их поддерживает):

• Windows NT
• Все 16-битные версии Windows и DOS (Windows 98, Windows 95, Windows 3.1)
• Debian 4.0 и 5.0
• Red Hat Enterprise Linux 2.1
• SUSE Linux Enterprise 8
• SUSE Linux Enterprise 9 младше SP4
• SUSE Linux Enterprise 10 младше SP3
• SUSE Linux Enterprise 11 младше SP1
• Ubuntu releases 8.04, 8.10, 9.04, 9.10 и 10.10
• Все релизы Novell Netware
• Все релизы IBM OS/2

Самые интересные исправления ошибок ожидают пользователей в подсистеме работы с хранилищами:

1. Наконец-то при выполнении операции Storage vMotion можно полноценно поменять имя виртуальной машины (то есть, целиком - вместе с виртуальными дисками).

Об этом мы уже писали вот тут. Наконец-то это заработало. На сервере vCenter идем в "Administration" -> "vCenter Server Settings" -> "Advanced Settings" и добавляем параметр:

provisioning.relocate.enableRename со значением true

2. Увеличенный VMFS Heap Size.

Об этом параметре мы уже писали вот тут:

Он применяется не только к VMFS3, но и VMFS5. Теперь вот что поменялось:

• VMFS Heap может расти до 640 МБ вместо 256 МБ в прошлом релизе. Это позволяет подключать к хосту ESXi совокупный объем хранилищ до 60 ТБ.
  
• Размер кучи выставляется дефолтно 640 МБ для новых установок и сохраняется на уровне уже имеющегося значения для апгрейдов с предыдущих версий.
• Появился новый параметр, позволяющий гарантировать размер кучи - VMFS3.MinHeapSizeMB. Но его нельзя выставить больше, чем 255 МБ (однако она может продолжать расти до 640 МБ).

3. WWNN и WWPN для адаптеров FC HBA отображаются в vSphere Web Client корректно.

Раньше там отображалась бурда в виде ноликов на конце (см. тут). Теперь это поправлено.

Кроме всего этого, появилась хорошая статья KB 2037630, описывающая порядок обновления различных компонентов виртуальной инфраструктуры, построенной на продуктах VMware:

Там же - очень полезная табличка со ссылками:

Скачать VMware vSphere 5.1 Update 1 можно по этой ссылке.

Иногда бывает так, что VMware ESXi может начать вести себя странно, но симптомы могут быть совершенно разными, например:

• Не работает vMotion - отваливается на 13% с ошибкой "A general system error occurred: Timed out waiting for vpxa to start" или зависает вовсе
• Не работает консоль виртуальной машины (Unable to contact the MKS)
• Не зайти на хост VMware ESXi по SSH
• Хост ругается на отсутствие свободного места, хотя оно есть на разделах ESXi (No free space left on device)
• и прочие неприятности

При этом иногда сходу и не скажешь, что произошло. А проблема вот в чем: у файловых систем ОС Unix есть объекты inode - структуры данных, где хранится метаинформация о стандартных файлах, каталогах или других объектах файловой системы, кроме непосредственно данных и имени. Так вот, этих inode - ограниченное количество, и при большом количестве файлов они могут просто закончиться.

Чтобы проверить количество доступных inodes надо выполнить следующую команду на VMware ESXi (подробнее в KB 1007638):

[root@esx /]$ stat -f /

Вывод будет похож на этот:

File: "/"
ID: 0 Namelen: 255 Type: ext2/ext3
Blocks: Total: 1259079 Free: 898253 Available: 834295 Size: 4096
Inodes: Total: 640000 Free: 580065

Вот тут мы видим, что из 640 тысяч айнодов свободно 580 тысяч, то есть все в порядке.

Откуда может взяться так много файлов? Оказывается это случается, когда включен демон SNMPD на VMware ESXi 5.1. Каталог /var/spool/snmp начинает быстро засираться файлами SNMP-трапов. Если у вас включен SNMP и в этом каталоге более 2000 файлов - вероятность возникновения описанного выше поведения высока.

Выход - почистить папку и сделать так, как написано в статье KB 2040707.

P.S. Кстати, интересная идея для злодеев.

С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).

Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.

С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.

Для получения информации об исправлении ошибки можно подписаться на KB 2042164.

Некоторые из вас знают, что компания VMware выпускает специализированный фреймворк VDDK (VMware Virtual Disk Development Kit), который позволяет просто обращаться с виртуальными машинами в контексте резервного копирования. Его используют практически все вендоры решений для РК виртуальных машин на платформе vSphere, например, Veeam Backup and Replication и Symantec BackupExec.

Не так давно было заявлено о том, что версия VDDK 5.1 может вызывать проблемы при использовании с VMware vSphere 5.1, что выражается в зависании и прерывании некоторых вызовов к функциям резервного копирования и восстановления (например, функции VixDiskLib_ConnectEx и VixDiskLib_Cleanup). Это описано в статье "Third-party backup software using VDDK 5.1 may encounter backup/restore failures", при этом проблема на сегодняшний день не имеет решения.

Так почему же пользователи продукта Veeam Backup and Replication этого не замечают? Все очень просто. Если прочитать статью "Symantec admits all its VMware backup customers are in danger", то становится понятным, что поскольку тестеры и разработчики Veeam давно работают с фреймворком VDDK (еще со времен VADP), то они уже успели понять, что это временами весьма глючная штука. Поэтому процессы Veeam Backup and Replication постоянно следят за работой служб VDDK, проверяют, не зависли ли они сами или их потоки, а в случае зависания (которое определяется грамотно выставленными таймаутами) - терминируют их безопасно для задачи РК. Мало того, в данный момент Veeam работает совместно с VMware над устранением данной проблемы.

Ну а как следует из названия упомянутой статьи, такой защиты у продуктов Symantec нет, поэтому пользователи Symantec BackupExec могут быть подвержены опасности зависания задач, а что еще хуже - проблеме неконсистентных бэкапов.

Для начала обратите внимание, что обновление вышло не для ESXi 5.1 (последней версии гипервизора), а для ESXi 5.0 - его предыдущей версии. Так что это обновление актуально только для тех, кто еще не успел переехать со старой версии платформы.

Помимо VMware ESXi 5.0 Update 2, вышел и VMware vCenter 5.0 Update 2. Новые возможности обновлений:

• Официальная поддержка работы vCenter 5.0 на Windows Server 2012.
• Официальная поддержка новых гостевых ОС: Oracle Solaris 11, Solaris 11.1, а также Mac OS X Server Lion 10.7.5.
• Поддержка сервером vCenter механизма Guest Operating System Customization для следующих гостевых ОС: Windows 8, Windows Server 2012, Ubuntu 12.04, RHEL 6.2, RHEL 6.3.
• Сервер vCenter Essentials больше не перехватывает лимит в 192 ГБ от старой модели лицензирования.
• Исправление ошибки, когда не работал таймаут SSH-сессии после выключения и включения сервиса SSH (хотя настройка сохранялась в конфиге).
• Исправление ошибки, когда в скриптовой установке не подхватывалось получение DNS-сервера хостом по DHCP, а вместо этого выставлялись ручные настройки.
• Исправление ошибки, когда при реинсталляции ESXi сохранялся лейбл локального датастора, который был задан ранее.
• Множественные багофиксы тут и тут, а также тут.

Скачать обновленные версии гипервизора ESXi 5.0 Update 2 и сервера vCenter 5.0 Update 2 можно по этой ссылке.

Для владельцев же новой версии VMware vSphere 5.1 также есть новости - вышел VMware vCenter 5.1b.

В основном этот релиз содержит множество исправлений ошибок, про которые можно прочитать вот тут. Наиболее значимые:

• Ошибки, связанные с истечением таймаутов при работе в VMware vSphere Client.
• Нельзя было залогиниться в vSphere Web Client как пользователь домена Active Directory с нестандартным UPN.

Скачать VMware vCenter 5.1.0b можно по этой ссылке.

Как многие знают, ядром концепции компании Citrix является идеология предоставления доступа пользователя к своим данным и приложениям из любой точки и с любого устройства.

На днях эта концепция дала сбой - из-за багов приложение Citrix Receiver 5.6.3, выпущенное 28 ноября под iOS, было удалено из App Store.

Потенциально это событие может может повлиять на те компании, в которых CIO убедили пользователей и руководство, что с помощью Citrix XenDesktop/XenApp можно быстро получать доступ к данным своего ПК cо своих iPad и iPhone. Они рассказали о всех модных фишках продукта, включая MDX и ShareFile, а теперь это приложение нельзя никак получить уже несколько дней!

Об этом есть официальная запись в блоге Citrix и некий workaround, заключающийся в том, чтобы поставить себе бета-версию приложения, которую можно найти, вбив "R1" в поиске App Store (функции, которые есть там, те же, что и в финальной версии Receiver):

Интересно то, что это так называемый "distribution bug" - то есть ошибка, не касающаяся непосредственно функциональности приложения, а касается она возможностей доступа к данным, сохраненным предыдущей версией Citrix Receiver на iOS-устройстве. Соответственно, после преодоления бюрократической машины Apple, с выпуском исправленной версии Receiver, эта ошибка в скором времени будет исправлена. На момент написания заметки (0:20 мск, 3 декабря) по запросу "Citrix" в App Store приложение Receiver так и не находилось.

Таким образом, за последнее время слажали все три основных вендора в сфере виртуализации:

• Citrix с недоступностью Reveiver
• Microsoft с SLA для Azure
• VMware с фэйковыми ценами для России

Ждем новых интересных событий от наших горячо любимых вендоров!

Мы уже писали о том, что после выхода новой версии платформы виртуализации VMware vSphere 5.1, оказалось, что она несовместима с последней версией решения для виртуализации настольных ПК предприятия - VMware View 5.1 (а также и с некоторыми другими продуктами). Происходило это из-за новой возможности View Storage Accelerator, которая при использовании функционала Content Based Read Cache (CBRC) приводила к многочисленным запросам CBRC, из-за которых терялась связь с хост-сервером ESXi 5.1.

В конце прошлой недели компания VMware, наконец, решила эту проблему, выпустив релиз VMware vSphere 5.1.0a, полностью поддерживающий View 5.1 (обратите внимание, что версия ESXi 5.1 не изменилась, т.е. обновлять нужно vCenter, а на ESXi 5.1 можно просто накатить патч ESXi510-201210001):

Обновленный ISO-образ гипервизора ESXi: VMware-VMvisor-Installer-201210001-838463.x86_64.iso. Подробности доступны в KB 2035268. Для обновления VMware vCenter 5.1.0a доступны Release Notes, где указаны исправленные ошибки. Странно, что патч накатывается не на компоненты VMware View 5.1, а на вышедшую позже платформу vSphere 5.1.

И еще одна приятная новость - вышел VMware Converter 5.0.1 с поддержкой vSphere 5.1. Вышел он аккурат после выпуска Microsoft Virtual Machine Converter Tool 1.0, который vSphere 5.1 не поддерживает, что как бы намекает.

Но это еще не все. Обновились также и следующие продукты:

• vSphere Data Protection (VDP) до версии 5.1.1
• vSphere Storage Appliance до версии 5.1.1
• VMware vCloud Director до версии 5.1.1
• VMware vCloud Networking and Security до версии 5.1.1

Обновляйтесь.

Не секрет, что продавать программное обеспечение сейчас - дело неблагодарное и низкомаржинальное, когда дело касается небольших сделок. Когда дело касается большой продажи - это, зачастую, лохотрон, потому как у многих вендоров есть пресловутый механизм "регистрации сделок", который уже давно прогнил и воняет как брошенный у деревенской остановки труп. Почему от него воняет? Очень просто - решение по регистрации сделок целиком лежит на аккаунте вендора, который может быть ангажирован со стороны одного из партнеров, который мотивирует первого разными способами, в том числе Чивасом в помпезном баре или квартальными бонусами. Об этом наши западные друзья, конечно же, знают, но закрывают на это глаза - продавать в Загнивающей как-то же надо.

Они-то знают, как тут строится бизнес и вынуждены работать по правилам, несмотря на то, что заставляют заполнять документы типа "Due Diligence Questionnaire", где сказано куда бежать, если заказчик вымогает взятку. Ну да ладно, речь не об этом.

Речь о том, что VMware на днях сделала доступным публично российский прайс-лист. Присядьте или возьмитесь за поручень и посмотрите:

У тех, кто отвечает за русский прайсинг в VMware - голоса в голове. Когда-то его сделали доступным, потом убрали, теперь он снова на арене, но в новом обличье! Давайте для сравнения заглянем в американский прайс:

И цены наших европейских братьев:

Ого-го, что мы видим. Всего-то мы видим воочию, своими собственными глазами, что:

У нас VMware в 2 раза дороже, чем в Америке.

И чуть поменьше, чем в 2 раза - по отношению к Европе. Это вам даже не Apple со своими Айпадами. Вы вот тут возмущались разнице в цене 30%? Теперь встаньте в стойло и кушайте разницу почти в 100%!

С чем же такое связано? Очень просто - прайс, который вы видите на русском сайте VMware - не совсем настоящий. Какой-то креативный человек в VMware решил провернуть инновационную штуку. А именно: повысить рекомендованные цены для пользователей в России, а для партнеров оставить их прежними (они хоть и не американские, но не в 2 раза же выше). Бедненькие партнеры же страдают со своей копеечной маржой. А тут - нате: давайте вместе считать пользователя мудотрясом и зарабатывать.

Скажу вам по секрету, что старая рекомендованная цена для российского пользователя - как и раньше на 30% выше американской. Поэтому мне ничего не остается, как сказать вам, какую цену вам требовать от партнера - прибавить 30% к американскому прайсу. Это будет адекватно. А этим пусть сама VMware пользуется.

P.S. Если вы донесете это до СМИ или напишете в Спортлото - будет хорошо.

Иногда при попытке вывести хост VMware ESXi из домена AD с помощью vSphere Client пользователь видит вот такую ошибку:

The operation is not allowed in the current state

В этом случае вам необходимо сделать "Clean up" конфигурации Active Directory. Для этого заходим в консоль хоста через DCUI или SSH и выполняем следующие команды:

1. Останавливаем демон lsassd:

/etc/init.d/lsassd stop

2. Удаляем папку db на хосте:

rm /etc/likewise/db/

3. Запускаем демон lsassd:

/etc/init.d/lsassd start

После этого выведение хоста ESXi из Active Directory должно пройти успешно.

После выхода финальной версии платформы виртуализации VMware vSphere 5.1 появились вопросы о том, как обстоят дела с совместимостью продукта с такими популярными решениями, как VMware View и Veeam Backup and Replication, а также другими корпоративными решениями.

Отвечаем вкратце - плохо.

Теперь подробнее. На тему совместимости VMware vSphere 5.1 с VMware View есть статья KB 2035268, где прямо указано, что версия vSphere 5.1 на данный момент не совместима ни с одной из версий решения VMware View (в том числе, последней - 5.1.1, которая была выпущена 16 августа).

Что касается Veeam Backup and Replication (последняя версия - 6.1), то VMware vSphere 5.1 также пока официально не поддерживается для резервного копирования виртуальных машин. Если вы попытаетесь сделать бэкап ВМ на одном из хостов ESXi, то получите следующее сообщение:

Error: Host with uuid 30303734-3536-5a43-4339-343030543957 was not found

Чтобы решить эту проблему, нужно сделать следующее:

1. Нажимаем Help--> License Information --> Licensed Hosts --> Select Host --> Revoke.
2. В vSphere Client создаем пустую ВМ на хосте ESXi, где возникла проблема.
3. Создаем backup job в продукте Veeam Backup and Replication и запускаем эту задачу для резервного копирования ВМ.

После этого задачи РК должны отрабатывать нормально, однако это на данный момент официально неподдерживаемая конфигурация. Нужно ждать версии Veeam Backup and Replication 6.5, которая должна подоспеть в ближайшем будущем.

Какие еще есть проблемы совместимости у VMware vSphere 5.1:

• У пользователей продукта Synology DSM
• Проблемы с PowerPath - не обновляйтесь, лекарства пока нет. Об этом написано в KB 2034796. Решить проблему обещают в сентябре.
• Проблема для Symmetrix Enginuity Microcode (VMAX 5875.x), где тома VMFS не создать из-за аппаратного ускорения массива (описано в Release Notes). На время создания нужно отключить Hardware Acceleration, для чего нужно поменять параметр VMFS3.HardwareAcceleratedLocking в Advanced Settings хост-сервера ESXi.

Знаете еще проблемы? Пишите в каменты.

Те из вас, кто уже установил Windows 8 RTM, спокойно лежащий на торрентах, возможно пытался установить туда VMware vSphere Client 5.0 Update 1. При установке возникает такая ошибка:

This product can only be installed on Windows XP SP2 and above

Решается такая проблема очень просто: для установщика в свойствах файла нужно поставить режим совместимости с Windows 7:

После этого все устанавливается нормально, однако при открытии vSphere Client на Windows 8 и попытке соединиться с консолью виртуальной машины, мы получаем вот такое сообщение:

The VMRC console has disconnected...attempting to reconnect.

А в Event Log мы увидим вот такую запись:

Application 'C:\Program Files (x86)\Common Files\VMware\VMware VMRC Plug-in\Internet Explorer\vmware-vmrc.exe' (pid 1408) cannot be restarted - Application SID does not match Conductor SID

Все просто - vSphere Client пока не совместим с Windows 8 из-за IE10. Обойти это пока никак нельзя (если знаете как - расскажите в каментах). Вместо этого пока используйте VMware Workstation 9, в которой есть возможность соединяться с консолью виртуальных машин на платформе VMware vSphere 5. Ждем решения от VMware, которой уже пора бы исправлять эту ошибку (будем надеяться, что в vSphere Client 5.1 ее уже нет).

Помните мы писали про баг VMware ESXi 5.0 Updare 1, где была проблема с неработающим авто-стартом виртуальных машин?

В конце прошлой недели были выпущены патчи для ESXi (Patch Release ESXi500-201207001), решающие эту проблему. Скачать их можно с портала патчей VMware, выбрав продукт ESXi версии 5.0.0 и дату - 12 июля:

Эти патчи включают в себя обновления подсистемы безопасности, а также множественные исправления ошибок, в том числе, фикс проблем Auto Start и SvMotion / VDS / HA :

Патчи описаны в KB 2019107.

Кроме этого, было также выпущено обновление сервера управления VMware vCenter Server 5.0 Update 1a:

Среди новых возможностей VMware vCenter:

• Поддержка следующих СУБД Oracle:
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 64 bit
• Oracle 11g Enterprise Edition, Standard Edition, Standard ONE Edition Release 2 [11.2.0.3] - 32 bit
• Смена БД vCenter Server Appliance - встроенная база данных DB2 Express теперь заменена на VMware vPostgres
• Несколько исправлений ошибок - их можно найти в секции Resolved Issues

Скачать VMware vCenter Server 5.0 Update 1a можно по этой ссылке.

Процедура обновления:

1. Сделайте резервную копию БД vCenter
2. Деинсталлируйте vCenter hot-patch (если он есть)
3. Установите новую версию, указав существующую БД

Не так давно мы упоминали о результатах тестирования решения для виртуализации настольных ПК предприятия VMware View 5, проведенного компанией Principled Technologies по поручению компании VMware. Продукт VMware View 5 в нем сравнивался с конкурирующим решением Citrix XenDesktop 5.5, при этом ПО от VMware выигрывало в производительности аналогу от Citrix для типовой нагрузки во многих категориях тестов.

Заголовком этого тестирования (есть также у нас в документах) от февраля 2012 года является фраза:

VMware View 5 Performed better than or equal to Citrix XenDesktop 5.5 with equivalent settings on Login VSI workloads simulating common office applications

Посыл данного заголовка понятен - VMware View производительнее и круче.

Титульная страница отчета выглядит следующим образом:

В компании Citrix возмутились таким положением дел: "Как так? Они тестируют XenDesktop для одного десктопа и рабочей нагрузки в сферической локальной сети и выставляют это за результат реального тестирования. Непорядок!". Тогда в Citrix решили обратиться к парням из Principled Technologies и спросили "Что за дела, пацаны? Наше решение круче себя ведет, когда на предприятии сотни виртуальных ПК, доступ ко многим из них происходит через WAN-сети, да и вообще мы давно делаем продукт и свой протокол ICA/HDX, поэтому так быть не должно!".

Сообразительные ребята из Principled Technologies почесали репу и говорят: "А давайте мы вам сделаем тоже отчет! Там как раз про все это будет: и про WAN, и про то, что у вас есть технологии всякие оптимизации канала, и про все остальные ваши навороты". Citrix сказал: "А давайте!". И получился еще один документ, уже от апреля 2012 года, являющийся также результатом тестирования продуктов, но уже по заказу Citrix, с красивым заголовком:

Citrix XenDektop Provided a better remote user experience via WAN vs. VMware View 5

Видимо за прошлое исследование парням из Principled Technologies было немного стыдно, поэтому "vs. VMware View 5" они написали мелким шрифтом:

Посыл этого документа тоже понятен - Citrix круче VMware (причем если почитать, то даже если настроить View по Optimization Guide). Поэтому пользователям предлагается поломать голову над текстом и картинками обох исследований, которые радуют глаз своими разными подходами к оценке продуктов.

Посмотрим на графики первого исследования (по заказу VMware - справедливости ради отметим, что с Flash Redirection показан лучше XenDesktop):

Взглянем на второй документ (по заказу Citrix):

В итоге, что мы имеем: одна контора подготовила для двух конкурирующих вендоров отчеты, которые по-разному формируют отношение к их продуктам. Надо полагать, за это были заплачены деньги, ведь делаются такие вещи небесплатно. Поэтому все это напоминает один старинный анекдот. Ну а чуваки из PT свое получили.

Теперь мы ждем очередного задания для Principled Technologies, уже от VMware, в котором мы узнаем, почему же все-таки нужно использовать VMware при доступе через WAN. Непорядок же...

При эксплуатации виртуальной инфраструктуры VMware vSphere иногда случается ситуация, когда виртуальную машину нельзя включить из-за того, что ее какой-нибудь из ее файлов оказывается залоченным. Происходит это при разных обстоятельствах: неудачной миграции vMotion / Storage vMotion, сбоях в сети хранения и прочих.

Наиболее распространенная ошибка при этом выглядит так:

Could not power on VM: Lock was not free

Встречаются также такие вариации сообщений и ошибок при попытке включения виртуальной машины, которое зависает на 95%:

• Unable to open Swap File
• Unable to access a file since it is locked
• Unable to access a file <filename> since it is locked
• Unable to access Virtual machine configuration

Ну а при попытке соединения с консолью ВМ получается вот такое:

Error connecting to <path><virtual machine>.vmx because the VMX is not started

Все это симптомы одной проблемы - один из следующих файлов ВМ залочен хост-сервером VMware ESXi:

• <VMNAME>.vswp
• <DISKNAME>-flat.vmdk
• <DISKNAME>-<ITERATION>-delta.vmdk
• <VMNAME>.vmx
• <VMNAME>.vmxf
• vmware.log

При этом залочил файл не тот хост ESXi, на котором машина зарегистрирована. Поэтому решение проблемы в данном случае - переместить ВМ холодной миграций на тот хост, который залочил файл и включить ее там, после чего уже можно переносить ее куда требуется. Но как найти тот хост ESXi, который залочил файл? Об этом и рассказывается ниже.

Поиск залоченного файла ВМ

Хорошо если в сообщении при запуске виртуальной машины вам сообщили, какой именно из ее файлов оказался залоченным (как на картинке выше). Но так бывает не всегда. Нужно открыть лог vmware.log, который расположен в папке с виртуальной машиной, и найти там строчки вроде следующих:

Failed to initialize swap file : Lock was not free

Тут видно, что залочен .vswp-файл ВМ.

За логом на экране можно следить командой (запустите ее и включайте ВМ):

tail /vmfs/volumes/<UUID>/<VMDIR>/vmware.log

Проверка залоченности файла ВМ и идентификация владельца лока

После того, как залоченный файл найден, нужно определить его владельца. Сначала попробуем команду touch, которая проверяет, может ли бы обновлен time stamp файла, т.е. можно ли его залочить, или он уже залочен. Выполняем следующую команду:

# touch /vmfs/volumes/<UUID>/<VMDIR>/<filename>

Если файл уже залочен, мы получим вот такое сообщение для него:

cannot touch: Device or resource busy

Дальше выполняем такую команду:

# vmkfstools -D /vmfs/volumes/<UUID>/<VMDIR>/<filename>

В значении "owner" мы видим MAC-адрес залочившего файл хоста VMware ESXi (выделено красным). Ну а как узнать MAC-адрес хоста ESXi - это вы должны знать. Дальше просто делаем Cold Migration виртуальной машины на залочивший файл хост ESXi и включаем ее там.

Те, кто хочет дальше изучать вопрос, могут проследовать в KB 10051.

Источник: "Could not power on VM - lock was not free".

Сейчас на VMware Communities обсуждается очередной баг в бесплатном гипервизоре VMware ESXi 5.0 Update 1 (он же vSphere Hypervisor). Приведенная ниже информация касается только пользователей бесплатного ESXi и не затрагивает владельцев любого из платных изданий vSphere.

Итак, когда вы обновляете VMware ESXi 5.0 на ESXi 5.0 Update 1, вы обнаруживаете неприятную особенность: функции Auto Start для виртуальных машин больше не работают (то есть машины при старте хост-сервера не запускаются). И это несмотря на то, что настройки автоматического запуска виртуальных машин работают:

Проблема начинается с билда 623860 и, повторимся, не касается платных изданий ESXi в составе vSphere. Слухи о том, что это, ходят разные: либо это новое ограничение бесплатного ESXi, либо обычный баг. Вроде бы все в итоге склоняются, что обычный баг. Сама VMware обещает поправить это в VMware vSphere 5.0 Update 2.

Если функции автоматического запуска виртуальных машин в бесплатном ESXi так важны, то вы можете откатиться до ESXi 5.0 просто нажав при загрузке Shift+R для входа в Recovery Mode, где можно откатить Update 1:

Более подробную информацию можно получить вот в этой статье на блогах VMware.

Если вы обновляли хосты VMware vSphere 4.1 на vSphere 5.0, то у вас может возникнуть ошибка "Operation timed out" при переходе хост-сервера ESXi 5.0 в состояние "Election", т.е. выбора мастера операций (см. нашу статью о VMware HA в vSphere 5.0).

Когда инициируется запрос "start" для FDM, агент не запускается и HA пытается переустановить его, что также заканчивается неудачно, поскольку он имеет правильную версию и вроде как установлен нормально. Однако HA в этом случае не работает. Детали вы найдете вот в этой ветке на VMTN.

Это очередное доказательство той мысли, которую мы доносим с выходом каждой новой мажорной версии vSphere - никогда не делайте апгрейд на новую версию, а всегда переустанавливайте хост-серверы ESXi (потому что баги выползают буквально с каждым релизом).

Для решения проблемы нужно сделать следующее:

1. Перевести хост в режим обслуживания (Maintenance Mode) и убрать с него все ВМ.
2. Скопировать файл /opt/vmware/uninstallers/VMware-fdm-uninstall.sh куда-нибудь во временную папку (например, /tmp)
3. Из приведенной выше папки (/tmp) запустить скрипт ./VMware-fdm-uninstall.sh
4. Будет небольшая задержка на выполнение скрипта.
5. Вывести хост из Mainenance Mode и на панели "Recent Tasks" убедиться, что vCenter начал переустановку агента.

Это, по-идее, должно помочь. Ну и не забывайте, что все логи VMware HA на хосте (а именно, FDM-агента) хранятся в файле var/log/fdm.log.

Очень полезной может оказаться не только указанная ветка Community, но и статья KB 2004429.

Update: проблема оказывается серьезнее - она касается также ситуации, когда вы просто накатили патчи на ESXi 5.0 (см. комментарии).

Интересный момент обнаружился на блогах компании VMware. Оказывается, если вы используете в кластере VMware HA разные версии платформы VMware ESXi (например, 4.1 и 5.0), то при включенной технологии Storage DRS (выравнивание нагрузки на хранилища), вы можете повредить виртуальный диск вашей ВМ, что приведет к его полной утере.

Об этом написано в документе vSphere 5.0 Availability Guide:

In clusters where Storage vMotion is used extensively or where Storage DRS is enabled, VMware recommends that you do not deploy vSphere HA. vSphere HA might respond to a host failure by restarting a virtual machine on a host with an ESXi version different from the one on which the virtual machine was running before the failure. A problem can occur if, at the time of failure, the virtual machine was involved in a Storage vMotion action on an ESXi 5.0 host, and vSphere HA restarts the virtual machine on a host with a version prior to ESXi 5.0. While the virtual machine might power on, any subsequent attempts at snapshot operations could corrupt the vdisk state and leave the virtual machine unusable.

По русски это выглядит так:

Если вы широко используете Storage vMotion или у вас включен Storage DRS, то лучше не использовать кластер VMware HA. Так как при падении хост-сервера ESXi, HA может перезапустить его виртуальные машины на хостах ESXi с другой версией (а точнее, с версией ниже 5.0, например, 4.1). А в это время хост ESXi 5.0 начнет Storage vMotion, соответственно, во время накатывания последовательности различий vmdk (см. как работает Storage vMotion) машина возьмет и запустится - и это приведет к порче диска vmdk.

Надо отметить, что такая ситуация, когда у вас в кластере используется только ESXi 5.0 и выше - произойти не может. Для таких ситуаций HA и Storage vMotion полностью совместимы.

Многие из вас используют продукт номер 1 для создания отказоустойчивых хранилищ StarWind Enterprise, позволяющий предоставлять общие хранилища для виртуальных машин через iSCSI. Это очень хорошая технология для небольших компаний и филиалов, использующих VMware vSphere, но не могущих себе позволить полноценную систему хранения с дублированными аппаратными компонентами. Напомним, что скоро продукт будет доступен для двухузловой конфигурации Microsoft Hyper-V, а также выйдет версия StarWind 5.8, где обещают еще больше нововведений.

Некоторые пользователи применяют доступ к таргетам iSCSI для StarWind изнутри виртуальных машин (например, можно использовать бесплатное издание StarWind). Однако с VMware vSphere 5 и адаптером vmxnet3 обнаружилась интересная проблема - согласно KB 2006277, драйвер vmxnet3 из комплекта vSphere 5 некорректно работает с большими кадрами Jumbo Frames. Это приводит к деградации производительности и потере сетевого соединения.

Какие есть выходы:

• Использовать драйвер vmxnet3 из комплекта VMware Tools для версии vSphere 4.x (можно загрузить тут)
• Использовать виртуальный сетевой адаптер vmxnet2 (Enhanced) или E1000 из комплекта vSphere 5

Надо отметить, что при соединении серверов ESXi 5 с хранилищами StarWind с настроенными Jumbo Frames полностью поддерживается. Также все работает и в конфигурации с томами RDM для виртуальных машин в режиме физической и виртуальной совместимости.

Компания VMware работает над решением проблемы для адаптера vmxnet3 и Jumbo Frames при работе из гостевой ОС. Спасибо Константину Введенскому за новость.

Мы уже писали о продукте vSphere vStorage Appliance (VSA), который позволяет создавать хранилища iSCSI для небольших инсталляций VMware vSphere 5 с функциями отказоустойчивости.

Один из наших читателей обнаружил интересную особенность VMware VSA при установке в триальном режиме:

Скачивал триальную версию, ключ не дали, нигде. Но, ведь все продукты работают без каких-либо ключей 60 дней, и нигде не написано, что для VSA это не так, даже наоборот - при инсталляции пишется, что без ввода ключа должен установиться и работать в триальном режиме. Я склоняюсь, что VSA глючит... может, русскоязычный Windows не нравится.

Это действительно проблема - на форумах уже попадались точно такие же вопросы от других людей, пока без ответов.

Когда мы ставили VMware VSA, то просто ввели партнерский ключик, и все заработало. А у вас, читатели, такой проблемы нет? Все работает в триальном режиме? Отпишитесь, плз, если есть такая же проблема.

Еще один интересный момент о VSA. Мы уже писали, что есть конфигурации VSA с двумя и с тремя хостами VMware ESXi. В частности, вот пример реализации с двумя хостами:

Однако, суть здесь в том, что в этом случае VMware vCenter у вас должен быть физический, а не в виртуальной машине, поскольку по своей сути кластер трехузловой. Более подробно можно почитать об этом в KB 2004834 (Running vCenter Server in a virtual machine within a VSA cluster is not supported).

То есть нужен либо физический vCenter, либо хост ESXi, не входящий в состав VSA-кластера, c vCenter в виртуальной машине.

И последнее о VMware VSA. Если вы все-таки планируете покупку VMware vSphere Essentials Plus и продукта дополнения VSA, у компании VMware сейчас есть хорошее промо - эти два продукта вместе существенно дешевле, чем по отдельности (есть отдельная позиция в прайсе). Это получается даже чуть дешевле, чем покупать vSphere 4 + vCenter VSA Addon. Так что имейте в виду (а покупайте у нас).

При внесении различных параметров в конфигурационные файлы виртуальной машины на VMware ESX могут возникнуть различные ошибки. При этом виртуальная машина может до некоторого времени работать корректно.

Есть способ проверить vmx-файл на предмет наличия в нем ошибок (опечаток, например, в путях к рабочим директориям и т.п.). Для этого есть команда:

/usr/bin/vmware-configcheck <путь к vmx-файлу>

Она проверяет его на соответствие правилам оформления, приведенным в файле /etc/vmware/configrules.

В случае успешной проверки результат будет таким:

А в случае неуспешной - будет выведен результат FAIL и описание ошибки конфигурации.

Оказывается, на сайте Microsoft есть калькулятор для сравнения цен на приобретение решений VMware vSphere и Microsoft Hyper-V (с другими компонентами System Center). Там есть три сценария внедрения виртуализации в организации: базовая консолидация, виртуализация для среднего и малого бизнеса (СМБ), а также виртуализация для Enterprise-сектора.

Если мы выберем виртуализацию для СМБ, то увидим такую картинку:

Красненьким выделено то, насколько по расчетам Microsoft дороже обходится решение от компании VMware. Интересная штука: Microsoft до сих пор не знает, что в VMware Essentials Plus горячая миграция vMotion входит (в этом можно убедиться тут). Во-вторых, цена на vSphere Essentials Plus указана неправильно, сейчас он стоит $3 844,50 (в калькуляторе же $3 495,00). Из чего мы делаем вывод, что Microsoft просто пофигу на свой калькулятор.

Кстати, раз уж мы порекламировали Microsoft, приведем ссылку на еще один калькулятор - уже от VMware, где, наоборот, приложение от Microsoft вызывает большие затраты (тоже туфтовый калькулятор):

Истина между, конечно.

Бывает такое, что при резервном копировании виртуальной машине VMware vSphere на томе NFS (не VMFS!) виртуальная машина перестает отвечать на пинги, консоль подвисает и с ней не соединиться по RDP.

Такие вещи случаются, когда вы используете Veeam Backup and Replication 5 в режиме Changed Block Tracking (CBT), то есть с отслеживанием изменившихся блоков для более быстрого резервного копирования. Связано это с особенностями работы NFS-лочек, которые могут "провисать" до 30 секунд, в течении которых машина и зависает.

Если это вас так сильно беспокоит, Changed Block Tracking можно просто отключить в настройках задачи резервного копирования Veeam Backup and Replication:

Но если отключите CBT - бэкапы будут делаться медленнее. Так что выбирайте.

Механизм VMware High Availability (HA) в VMware vSphere позволяет автоматически перезапустить виртуальные машины отказавшего сервера в кластере с общего хранилища в случае сбоя. При настройке кластера VMware HA можно использовать несколько расширенных настроек (HA Advanced Settings), которые позволяют настроить его работу наиболее гибко.

Интересную проблему тут обнаружили некоторые товарищи (а раньше вот тут). Вроде как при обычной установке VMware ESXi (в том числе, версии 4.1) для физических сетевых адаптеров (pNic) 1Gbit выставляется настройка не Auto Negotiate, а 1000 Mbit Full Duplex.

А вот лучшие практики VMware (например, KB 1004089) говорит нам, что лучшая настройка - это Auto Negotiate как на адаптере, так и на порту физического коммутатора, куда включен хост (можно использовать также и 1000<->1000):

Но вот 1000<->Auto как мы видим не является хорошей практикой, ибо Auto Negotioation включает в себя договаривание устройств не только о скорости и дуплексе, но и такие параметры, как flow control, backpressure, inter-frame packet timing (наверное, там еще страшные слова есть).

Таким образом, нужно либо на свиче также поставить настройку 1000 - Full Duplex, либо поменять на хосте VMware ESX настройки в Auto для сетевых адаптеров:

Можно сделать это также через PowerShell / PowerCLI методами:

Get-VMHostNetworkAdapter | Set-VMHostNetworkAdapter –AutoNegotiate

Можно через командную строку:

[root@server root]# esxcfg-nics -a vmnic1

Если что не так - поправьте, пожалуйста, сам я это сейчас посмотреть не могу.

Часто разговаривая с заказчиками и пользователями платформ виртуализации от VMware, я вижу, что у многих из них весьма широко применяются снапшоты (snapshots), в том числе для целей "резервного копирования". Эти снапшоты живут долго, их файлы разрастаются и поростают плесенью. Потом инфраструктура начинает тормозить, а пользователи не знают почему. И как это не казалось бы странным - удаление всех снапшотов у всех виртуальных машин решает их проблемы, с которыми они уже свыклись.

Сегодня я вам расскажу, чтоб вы наконец запомнили: снапшоты это в целом плохо и лишь иногда хорошо. На эту страницу мы с вами будем отсылать наших клиентов и пользователей виртуальных машин, которыми могут оказаться люди, не участвующие в процессе администрирования VMware vSphere, но пользующиеся функционалом снапшотов (например, веб-разработчики).

Начнем с того, когда снапшоты могут помочь (я имею в виду, конечно, руками делаемые снапшоты, а не автоматические, которые делает, например, Veeam Backup).  Снапшоты в VMware vSphere оказываются полезны в очень ограниченных условиях (например, для проверки корректности работы обновления приложения или патча операционной системы). То есть эта та точка сохранения состояния виртуальной машины, к которой можно будет вернуться через небольшой промежуток времени. Ни в коем случае нельзя рассматривать снапшоты как альтернативу резервному копированию основных производственных систем, в силу множества проблем, о которых пойдет речь ниже.

Что плохого в снапшотах виртуальных машин на VMware ESX:

1. Снапшоты неконтролируемо растут (блоками по 16 МБ). Помимо базового диска ВМ фиксированной емкости вы имеете еще один файл отличий виртуального диска, который растет как ему вздумается (предел роста одного снапшота - размер базового диска). Особенно быстро растут снапшоты для ВМ с приложениями с большим количеством транзакций (например, почтовый сервер или сервер СУБД). Со снапшотами вы не имеете контроля над заполненностью хранилищ.

2. Большое количество снапшотов (особенно цепочки, в которых может быть до 32 штук) вызывает тормоза виртуальной машины и хост-сервера ESX (в основном замедляется работа с хранилищем). Проверено на практике. Даже VMware пишет так: "An excessive number of snapshots in a chain or snapshots large in size may cause decreased virtual machine and host performance". В качестве примера можно привести тот факт, что при аллокации блоков снапшота происходит блокировка LUN (в этом режиме он доступен только одному хосту, остальные ждут). Когда снапшот делается - машина подвисает из-за сброса памяти на диск.

3. Снапшоты не поддерживают многие технологии VMware, созданные для автоматизации датацентров. К ним относятся VMware Fault Tolerance, Storage VMotion и другие. Когда одни машинки в чем-то участвуют, а другие не участвуют - это нехорошо в рамках концепции динамической инфраструктуры.

4. Снапшоты вызывают специфические проблемы при операциях с ВМ. Например, расширение диска виртуальной машины со снапшотом приводит к потере данных и непонятками, что дальше с такой машиной делать. Сто раз уже пользователи влипали (вот как вытянуть себя за волосы). Интересно также восстановить из снапшота машину с IP-адресом, который на данный момент уже используется в сети.

5. Со снапшотами бывают баги, а бывает, что они просто "by design" тупят.

6. У снапшотов было плохое поведение при их слиянии, но сейчас исправилось.

Рекомендации по работе со снапшотами:

1. Контролируйте наличие снапшотов у виртуальных машин и их размеры, своевременно удаляйте их совместно с владельцами систем. Делать это можно, например, с помощью RVTools.

2. Не храните снапшоты больше 24-72 часов. Этого времени достаточно, чтобы оттестировать обновление ПО или патч ОС (ну и, конечно, сделать бэкап).

3. На сервере VMware vCenter можно настроить алармы на снапшоты виртуальных машин. Сделайте это. Дрючьте пользователей за необоснованные снапшоты.

4. Не позволяйте делать больше 2-3 снапшотов для виртуальной машины в принципе, если это делается в производственной среде. На своих выделенных для тестирования ресурсах (изолированных) пусть разработчики делают что хотят.

5. Если вы используете ПО для резервного копирования через снапшоты ВМ (например, Veeam Backup), помните, что бывает некоторые невидимые в vSphere Client снапшоты (Helpers) остаются на хранилище. Поглядывайте за машинами из командной строки.

6. Почитайте: KB 1009402, KB 1025279, KB 1015180.

Вчера и сегодня пользователи решения для виртуализации корпоративных ПК предприятия VMware View 4.5 обнаружили неприятную особенность, когда попытались с помощью VMware View Client соединиться с сервером View Connection Server - клиент не коннектится.

Это произошло по причине того, что на Windows 7 вы накатили какой-либо из вот этих патчей: 2482017 или 2467023. Выходов два:

• Не устанавливать эти патчи или откатить их для дальнейшего использования VMware View Client
• Установить обновление VMware View Client, которое можно скачать здесь (просто удалите предыдущую версию клиента через Add/Remove Programs и поставьте эту).

Подробнее в KB 1034262.

При установке VMware View Composer 2.5 из комплекта VMware View 4.5 у вас могут возникнут следующие 2 вида ошибок:

• VMware View Composer - Unable to open firewal
• VMware View Composer - Unable to close firewal

То есть, если у вас выключен фаервол Windows Server, то будет ошибка "open firewall", а если включен - то "unable to close". При этом вы запускете установку под администратором.

Решение: запустить установку, нажав правой кнопкой мыши на файле установки View Composer и выбрав "Run As Administrator". Парадоксально, но факт - работает.